The present invention deals with a device to be connected to a network and especially its installation and configuration. Installation is a general concept that covers all the hardware operations needed to connect the device to a network. Similarly configuration is understood to cover all the software operations that enable controlled transmission of data in the network between the device concerned and other devices connected to the network. The invention does not limit the type of network in question: it can be the Internet, an intranet, a Local Area Network (LAN), a Wide Area Network (WAN) or any other network intended for transmission of data between electronic terminals. The physical form of the network may be Ethernet(, Token Ring(, cellular radio network or any other corresponding network known as such.
Intelligent network devices, such as routers, VPN (Virtual Private Network) devices, print servers, network printers, network cameras, and telecommunications adapters, require detailed configuration data before they can transmit and receive information through the network in a controlled manner. For instance in an IP (Internet Protocol) network the device needs to know its own IP address and the address of the default gateway, and possibly lots of other configuration data.
Information travels through the network generally in the form of packets. As background information for the invention, two known addressing schemes for IP packets are described, namely the IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) packet headers. The layout of an IPv4 packet header is illustrated in FIG. 1, and the layout of an IPv6 packet header is illustrated in FIG. 2. Column numbers in FIGS. 1 and 2 correspond to bits.
In FIG. 1, the fields of the known IPv4 header are as follows: Version Number 101, IHL 102, Type of Service 103, Total Length 104, Identification 105, Flags 106, Fragment Offset 107, Time to Live 108, Protocol 109, Header Checksum 110, Source Address 111, Destination Address 112, Options 113 and Padding 114. In FIG. 2, the fields of the known proposed IPv6 header are as follows: Version Number 201, Traffic Class 202, Flow Label 203, Payload Length 204, Next Header 205, Hop Limit 206, Source Address 207 and Destination Address 208. The use of the fields in the headers is known to the person skilled in the art. An IP packet consists of a header like that of FIG. 1 or 2 accompanied by a data portion. In IPv6, there may be a number of so-called Extension headers between the main header shown in FIG. 2 and the data portion.
In a network where security features are important, an authentication may be performed by computing a Message Authentication Code (MAC) using the contents of the packet and a shared secret key, and sending the computed MAC as a part of the packet in an AH (Authentication Header) or ESP (Encapsulating Security Payload) header. Privacy is typically implemented using encryption, and the ESP header is used. The AH header is illustrated in FIG. 3, where column numbers correspond to bits. The fields of the known AH header are as follows: Next Header 301, Length 302, Reserved 303, Security Parameters 304 and Authentication Data 305. The length of the last field 305 is a variable number of 32-bit words.
The Encapsulating Security Payload (ESP) may appear anywhere in an IP packet after the IP header and before the final transport-layer protocol. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to ESP. The header immediately preceding an ESP header will always contain the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IP datagram or an upper-layer protocol frame (e.g., TCP or UDP). A high-level diagram of a secure IP datagram is illustrated in FIG. 4a, where the fields are IP Header 401, optional other IP headers 402, ESP header 403 and ecrypted data 404. FIG. 4b illustrates the two parts of an ESP header, which are the 32-bit Security Association Identifier (SPI) 405 and the Opaque Transform Data field 406, whose length is variable.
Several existing solutions are being used to configure newly installed network devices. Some devices have a display and keyboard for entering configuration data. Others may have a serial port in the device so that it can be attached to a separate configuration terminal for configuration. There are also solutions where a broadcast network packet or a ping packet is used to configure the device.
Solutions based on having a display and keyboard are often too costly and cumbersome for users. Likewise, attaching a configuration terminal to the device is an extra burden for the user. Methods based on broadcast packets only work in the local network, and cannot be used to configure the device remotely. Remote configuration is becoming more and more desirable, as the number of installed network devices is growing much faster than the number of people skilled enough to configure them. Finally, methods based on a ping packet can be used to configure the device remotely, but are limited in the amount of configuration data. Also, such methods will not work if the device to be configured is behind a device that is also listening for several other configuration packets or if there are similar identical devices on the same network.
Growing use of networks, especially increasing use of the Internet for electronic commerce and corporate communications is making security ever more important. Attacks against the network infrastructure are increasingly common. One opportunity for performing such attacks is the moment when the network device is being configured. At that time, most devices do not provide any security, and the attacker will be able to load the device with his/her configuration and software. The compromised device can then be instrumental in furthering the attack.
The existing configuration methods for configuring network devices lack ease of use, robustness, and security. Problems during device configuration are often very. difficult for users to understand and solve. It is therefore desirable to provide a method and apparatus for loading configuration data into the network device in a reliable, easy-to-use manner from a network management station controlled by an employee skilled in configuration of new network devices. This allows physical installation of new network devices to be carried out by employees that are not as skilled in configuration of new network devices. This genus of methods and apparatus will be referred to as the unsecure, remote configuration class. Further, in some networks where security is an issue, it is desirable to be able to configure new network devices remotely and securely from a remote network management station. This allows remote configuration via network packets without fear that an interloper with intent to attack the network will be able to intercept and alter the configuration data or other information such as network address or device identifier. The object of this invention is to provide methods, as well as a network device which can carry out the disclosed methods.
The object of the unsecure, remote configuration methods of the invention is accomplished by installing the network device in a dummy mode, and sending a configuration packet, including a device-specific identifier, to the network device to be configured or reconfigured either by broadcasting a packet containing the new network device""s device identifier or sending a configuration packet directly to the network device""s network address with the packet containing the device identifier of the device to be configured. The new network device to be remotely configured then either recognizes its device identifier in the broadcast packet or recognizes its device identifier in the packet sent directly to its network address, and uses the data therein to configure itself.
The object of the secure, remote configuration methods of the invention is accomplished by: transmitting the configuration packet from a remote network management station to the network device to be configured or reconfigured either by broadcast or by direct transmission to the network address of the device to be configured, authenticating the configuration packet at the network device to be configured or reconfigured as being from the proper network management station and containing the proper device identifier or by at least verifying that the configuration packet contains the properly encrypted device identifier which could only have been encrypted by the authentic network management station or some other secure information derived from the device identifier which can serve as a reliable indicator of the source of the configuration packet, and then decrypting and using the contents of the authenticated packet to configure the new network device.
It is characteristic of the secure, remote configuration method according to the invention that it comprises the steps of
transmitting from the management station a configuration packet to the network device,
authenticating at the network device the management station as the genuine transmitter of the configuration packet and
decoding the configuration parameters contained in said configuration packet and storing them as the configuration parameters of the network device.
The invention applies as well to a network device, of which it is characteristic that it comprises a computing block arranged to
compute device identifiers from cryptographic keys derived from recognised packets and
compare computed device identifiers against information used to verify known device identifiers for authentication of transmitting parties.
According to the invention, each new network device to be configured has a device identifier used to authenticate the device. There is also a management station connected to the network and used to remotely configure freshly installed network devices. The invention does not limit the nature of the device identifier; on the contrary, it should be understood very generally as something that can be used to identify a network device. According to a first embodiment of the invention, the management station knows the device identifier, IP address, default gateway, and other information needed to configure each new network device. When a new network device has been installed into the network it operates initially in a dummy mode where it only reads device identifiers from the packets it receives but does not otherwise process any data transferred in the network (or processes data in a factory-configured manner). The management station sends a specially formatted packet to the broadcast address of the network in which the new network device resides. The special packet contains an identifying code derived from the device identifier of the new network device and possibly other data. Whenever the new network device receives a packet, it checks whether the packet is a special packet with the identifying code matching its own device identifier. If the code matches, the device decodes the special packet, retrieves the configuration information from it and starts using its new configuration. It may also engage in a further information exchange with the management station to obtain further configuration data and to provide feedback to the management station user. In place of the identifying code derived from the device identifier the packet sent by the management station could also be a factory-configured (or generally preconfigured) address other than IP address, e.g. ethernet address, or some other kind of device identifier that the network will recognize.
According to a second embodiment of the invention the network device has its P address preconfigured manually before it is installed in the network. Thereafter, the management station may send a configuration packet directly to that address; the network device may even send a packet first to a preconfigured management station address to let it know it is there and wants to be configured.
According to a third embodiment of the invention the network device may obtain its IP address automatically from the network, e.g. using DHCP (Dynamic Host Configuration Protocol). According to a fourth embodiment of the invention the network device might respond to an ARP (Address Resolution Protocol) packet for IP addresses of some format, e.g. after a short delay to give a possible real owner of the address time to respond.
Security against any network-level attacks can be provided with the method. The device identifier is most advantageously derived from a cryptographic public key. The device identifier may also be the cryptographic key itself or a certificate accompanying it. Both the new network device and the management station may know the other device""s device identifier beforehand so that they may recognise a received packet as coming from the correct sender. Alternatively each device may display the identifier computed from data received from the other party to the user and have the user confirm that the identifier is correct. This is called a (manual) verification of the device identifier. Both the new network device and the management station verifies that the cryptographic public key received from the other side matches the (manually) verified device identifier. Then, they cryptographically generate a shared secret using the authenticated cryptographic public keys. One implementation of this is to have each cryptographic public key be a Diffie-Hellman public value. After the authentication and verification stages the configuration may proceed safely.
The present invention provides a method to remotely configure a network device in a reliable, easy-to-use manner from a separate management station (which can be another network device). Optionally, the method can provide security.
The method enables devices to be installed by fairly unskilled support personnel, and the technically more demanding configuration operation can be performed by an expert from a management station without needing to travel to the installation site.